After losing a fair bit of hair due to quality and reliability issues
with our home laser multifunctional (
Brother
DCP1600-series,
which we bought after checking it was meant to work on Linux And it
does, but with a very buggy, proprietary driver Besides being the
printer itself of quite low quality), we decided it was time to survey
the market again, and get a color inkjet printer. I was not very much
an enthusiast of the idea, until I found all of the major
manufacturers now offer refillable ink tanks instead of the darn
expensive cartridges of past decades. Lets see how it goes!
Of course, with over 20 years of training, I did my homework. I was
about to buy an Epson printer, but decided for an
HP Ink Tank 410
Wireless
printer. The day it arrived, not wanting to fuss around too much to
get to see the results, I connected it to my computer using the USB
cable. Everything ran smoothly and happily! No driver hunting needed,
print quality is superb I hope, years from now, we stay with this
impression.
Next day, I tried to print over WiFi. Of course, it requires
configuration. And, of course, configuration
strongly wants you to
do it from a Windows or MacOS machine which I don t have. OK, fall
back to Android For which an app download is required (and does not
thrill me, but what can I say. Oh and the app needs
location
services to even run. Why Maybe because it interacts with the
wireless network in
WiFi Direct, non-authenticated way?)
Anyway, things seem to work. But they don t My computers can
identify and connect with the printer from CUPS, but nothing ever
comes out.
Printer paused, they say. Entering the printer s web
interface is somewhat ambiguous Following the old HP practices, I
tried
http://192.168.1.75:9100/ (no point in hiding my internal IP),
and got a partial webpage sometimes (and nothing at all
othertimes). Seeing the printer got detected over
ipps://, my
immediate reaction was to try pointing the browser to port 631. Seems
to work! Got some odd messages But it seems I ll soon debug the
issue away. I am not a familiar meddler in the dark lands of
cups,
our faithful print server, but I had to remember my toolkit..
# cupsenable HP_Ink_Tank_Wireless_410_series_C37468_ --release
Sucess in enabling, but self-auto-disabled right away
lpstat -t
was not more generous, reporting only it was still paused.
Some hours later (mix in attending kids and whatnot), I finally
remember to try
cupsctl --debug-logging, and magically,
/var/log/cups/error_log turns from being quiet to being quite
chatty. And, of course, my first print job starts being processed:
D [10/May/2020:23:07:20 -0500] Report: jobs-active=1
(...)
D [10/May/2020:23:07:25 -0500] [Job 174] Start rendering...
(...)
D [10/May/2020:23:07:25 -0500] [Job 174] STATE: -connecting-to-device
(...)
Everything looks fine and dandy so far! But, hey, given nothing came
out of the printer keep reading one more second of logs (a couple
dozen lines)
D [10/May/2020:23:07:26 -0500] [Job 174] Connection is encrypted.
D [10/May/2020:23:07:26 -0500] [Job 174] Credentials are expired (Credentials have expired.)
D [10/May/2020:23:07:26 -0500] [Job 174] Printer credentials: HPC37468 / Thu, 01 Jan 1970 00:00:00 GMT / 28A59EF511A480A34798B6712DEEAE74
D [10/May/2020:23:07:26 -0500] [Job 174] No stored credentials.
D [10/May/2020:23:07:26 -0500] [Job 174] update_reasons(attr=0(), s=\"-cups-pki-invalid,cups-pki-changed,cups-pki-expired,cups-pki-unknown\")
D [10/May/2020:23:07:26 -0500] [Job 174] STATE: -cups-pki-expired
(...)
D [10/May/2020:23:08:00 -0500] [Job 174] envp[16]="CUPS_ENCRYPTION=IfRequested"
(...)
D [10/May/2020:23:08:00 -0500] [Job 174] envp[27]="PRINTER_STATE_REASONS=cups-pki-expired"
My first stabs were attempts to get CUPS not to care about expired
certificates, but it seems to have been hidden or removed from its
usual place. Anyway, I was already frustrated.
WTF Well, yes, turns out that from the Web interface, I paid some
attention to this the first time around, but let it pass (speaks
wonders about my security practices!):
So, the
self-signed certificate the printer issued at itself expired
116 years before even being issued. (is this maybe a Y2k38 bug?
Sounds like it!) Interesting thing, my CUPS log mentions the printer
credentials to expire at the beginning of the Unix Epoch
(
01 Jan 1970 00:00:00 GMT).
OK, lets clickety-click away on the Web interface Didn t take me
long to get to
Network Advanced settings Certificates:
However, clicking on
Configure leads me to the not very
reassuring
I don t remember what I did for the next couple of minutes. Kept
fuming Until I parsed again the output of
lpstat -t, and found
that:
# lpstat -t
(...)
device for HP_Ink_Tank_Wireless_410_series_C37468_: ipps://HPF43909C37468.local:443/ipp/print
(...)
Hmmmm CUPS is connecting using good ol port 443, as if it were a
Web thingy What if I do the same?
Click on New self-signed certificate , click on
Next, a couple of
reloads And a very nice color print came out of the printer, yay!
Now, it still baffles me (of course I checked!): The self-signed
certificate is now said to come from
Issuer : CN=HPC37468, L=Vancouver, ST=Washington, C=US, O=HP,OU=HP-IPG,
alright not that it matters (I can import a more meaningful one if I really feel like
it), but, why is it
Issued On: 2019-06-14 and set to
Expires On: 2029-06-11?
Anyway, print quality is quite nice. I hope to keep the printer long
enough to rant at the certificate being expired in the future!
Only... _Some_ blocking did hurt Telmex's users: The ability to play
an active role in Tor. The ability to host Tor relays at home. Why?
Because the *consensus protocol* requires relays to be reachable in
order to be measured from the network's *DirAuths*.
### Technical work to prove the blocking
We dug into the issue as part of the work we carried out in the
project I was happy to lead between 2018 and 2019, *UNAM/DGAPA/PAPIME
PE102718*. In March 2019, I presented a paper titled [Distributed
Detection of Tor Directory Authorities Censorship in
Mexico](https://www.thinkmind.org/index.php?view=article&articleid=icn_2019_6_20_38010)
([alternative download](http://ru.iiec.unam.mx/4538/) in the [Topic on
Internet Censorship and Surveillance (TICS) track](https://tics.site/)
of the XVIII International Conference on Networks.
Then... We had many talks inside our group, but nothing seemed to move
for several months. We did successfully push for increasing the number
of Tor relays in Mexico (we managed to go from two to eleven stable
relays not much in absolute terms, but quite good relatively, even
more considering most users were not technically able to run one!)
Jacobo N jera, journalist participant of our project, didn't leave
things there just lying around waiting magically for justice to
happen. Together with Vasilis Ververis, from the [Magma
Project](https://magma.lavafeld.org/), they presented some weeks ago a
[Case study: Tor Directory Authorities Censorship in
Mexico](https://magma.lavafeld.org/guide/data-analysis.html#case-study-tor-directory-authorities-censorship-in-mexico).
### Pushing to action
But a good part of being a journalist is knowing _how_ and _when_ to
spread the word. Having already two technical studies showing the
blocking in place, Jacobo presented his findings with [an article in
GlobalVoices: *The largest telecommunications operator in Mexico
blocks the secure
network*](https://es.globalvoices.org/2020/05/28/en-mexico-el-mas-grande-operador-de-telecomunicaciones-bloquea-la-internet-segura/). Surprisingly
(to me, at least), this story was picked up by a major Mexican
newspaper: The same evening the story hit GlobalVoices, [Rodrigo
Riquelme](https://www.eleconomista.com.mx/autor/rriquelme) posted an
article, in the Technology section of *El Economista*, titled [Telmex
blocks seven out of ten accesses to the Tor network in
Mexico](https://www.eleconomista.com.mx/tecnologia/Telmex-bloquea-siete-de-10-accesos-a-la-red-Tor-en-Mexico-20200528-0078.html). And
that very same day, Telmex sent a reply I am translating in full (that
is now included at the end of Riquelme's article):
> Mexico City, May 28, 2020
>
> In relation to Tor navigation from TELMEX's network, the company
> informs:
>
> In TELMEX, we are committed to the full respect to navigation
> freedom for all of our users.
>
> TELMEX practices no application-level blocking policies; the Tor
> application, as well as the rest of Internet applications, can be
> freely accessed from our network.
>
> In order to protect the Internauts' information, the seven refered
> nodes were in their time reported because they were associated with
> the distribution of the WannaCry ransomware, which is the reason
> they were filtered, but this does not hamper the use of the Tor
> application.
### So we got an answer...?
Jacobo knew we had to take advantage of this answer, and act fast! He
entered rush-writing mode and, with the help of our good friend and
lawyer Salvador Alc ntar, we wrote [a short letter to Renato Flores
Cartas, Corporative Communication of Am rica
M vil](https://internetanonima.net/respuesta-a-telmex-sobre-la-red-tor-en-mexico/),
and sent it on June 1st.
Next thing I know, this evening Jacobo was asking me if I could
confirm the blocking was lifted. What I could not believe it! But,
yes Today Jacobo published the confirmation that [the seven blocked
IP routes were finally reachable again from ASN 8151 (UNINET / Telmex
/ Am rica
M vil)!](https://internetanonima.net/confirmamos-desbloqueo-de-las-7-direcciones-de-la-red-tor-por-telmex/)
Of course, this story was picked up again by El Economista [Telmex
unblocks IP addresses for the Tor network's directory authority server
IPs in
Mexico](https://www.eleconomista.com.mx/tecnologia/Telmex-desbloquea-direcciones-IP-de-servidores-de-autoridad-de-la-red-Tor-en-Mexico-20200604-0094.html).
### Wrapping up
How can I put this in words? I am very, very, very, *very, very,
very*, **very, very, very** happy we managed to see this through!
Although we have been pushing for increasing the usage of Tor among
users at risk in Mexico Being a journalist, defending human rights,
are still a high-risk profession in my country. We strongly believe in
this, and will continue trying to raise awareness of the usage.
But, just as with free software, *using* network anonymization tools
is not all. We need more people to become active, to become engaged,
to *become active participants* in anonymization. As the adage says,
*anonymity loves company* In order to build strong, sufficient
anonymization capability for everybody that needs it, we need more
people to *provide relay services*. And this is a *huge* step to
improve Mexico's participation in the Tor network!
---
Image credits: [*Seeing My World Through a Keyhole*, by Kate Ter
Haar](https://www.flickr.com/photos/katerha/4592429363) (CC-BY); [Tor
logo (Wikimedia Commons)](https://commons.wikimedia.org/wiki/File:Tor-logo-2011-flat.svg)
So, we are already halfway through DebCamp (which means, you can come
and hang out with us in the 
